Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.

📢 Thoughts on this report? Let us know!

Should the new validation script be run in CI? Maybe after #67, because that touches the Validation workflow

Should the new validation script be run in CI? Maybe after #67, because that touches the Validation workflow

One issue with always running validation in CI is that there will probably need to be some heavy validation cases. So we may not be able to run them all (or at least not all the time... maybe infrequently, eg nightly or weekly)

Another thought is that I think its nice to implement validation cases as "examples" which get built into the documentation (Oceananigans does this to some extent, though we may be able to do an even better job here).

However one may want to have additional validation cases that are not examples. Some of the non-example validation cases could be lightweight enough to run regularly in CI.

Maybe we can flesh out a strategy that incorporates these considerations?

Yes. Agree.

It's bit tricky to run the validation cases in a CI. Especially if validation cases also start plotting things and one needs to visually inspect to ensure that nothing changed. An idea would be that validation scripts finish at

run!(simulation)

plus perhaps a very simple test after (eg something to ensure the flow is not nonsense?)

simulation.model.tracers.temperature < 300

And then different scripts for plotting? It does make the validation directory a bit more complex...

Possibly we want to implement validation tests as regression tests.

This mountain wave case is not working too well in terms of speed and fidelity for the following reasons

1. Immersed boundary requires very high resolution to resolve the short mountain.
2. Open boundary condition is needed to improve the solution.

At least, the phase of the most significant wave looks not too bad!

This mountain wave case is not working too well in terms of speed and fidelity for the following reasons

1. Immersed boundary requires very high resolution to resolve the short mountain.
2. Open boundary condition is needed to improve the solution.

At least, the phase of the most significant wave looks not too bad!

Great work @kaiyuan-cheng ! This is indeed a challenging test for z-coordinate, so it is quite useful. My two big comments are 1) can we see what the solution looks like at high resolution (I understand that we need to get GPU working for that --- I will look at that in parallel) and 2) can we investigate whether vertical grid stretching helps?

Some more detail below.

Here are my takeaways:

• for simulations that use a z-coordinate wherein the terrain is very low-lying, we may need very high resolution to resolve the physics correctly
• for low resolution simulations with low-lying terrain and/or deep domains, we will probably want to implement a terrain following coordinate
• (we should work on validation cases that don't have topography too)

here are my existing questions:

• does grid stretching (packing resolution near the bottom of the domain) improve accuracy?
• what resolution is required for accuracy (perhaps expressed as "how well is the terrain resolved")?
• what are the characteristics of simulations where we deem that we should move to a terrain following coordinate (horizontal resolution, vertical resolution, domain depth, topography characteristics)?
• "how much" can we stretch the grid before accuracy breaks down? The usefulness of stretching has a limit.
• How much fidelity do we buy by using a better representation of the terrain in a z-coordinate --- eg cut cells versus partial cells?

a few comments:

• if we are using a terrain-following coordinate, I think we should also probably move to a fully compressible formulation. The reason is that an anelastic solver for terrain-following coordinates may incur a similar expense as acoustic substepping. (I do think it should be theoretically possible to develop a fast enough solver, but that work is difficult and the gains will probably be marginal)
• I think a cut cell implementation is similar or harder than terrain following coordinate, so we shouldn't think of cut cells as a "silver bullet". We should pursue cut cells if partial cells work "ok" and cut cells are an optimization. (the best is of course to pursue both...)

At some point we should open an issue to discuss the pros and cons.

Tagging @OsKnoth, @bischtob because he basically told me all of the points that I made above 😂

Also tagging @simone-silvestri since I suspect he will be intrigued by acoustic substepping AND terrain following coordinate implementations (whose work could possibly inform the ocean model as well) --- although my hunch is that maintaining restful hydrostatic balance is harder in the ocean due to (1) bigger topography relative to depth (it goes to the top) and (2) possibly, equation of state difficulties.

@kaiyuan-cheng can you also push your changes to this PR so we can see your code?

@kaiyuan-cheng can you also push your changes to this PR so we can see your code?

I pushed it last night. Here is the link. Let me know if you have trouble accessing it.

This mountain wave case is not working too well in terms of speed and fidelity for the following reasons

1. Immersed boundary requires very high resolution to resolve the short mountain.
2. Open boundary condition is needed to improve the solution.

At least, the phase of the most significant wave looks not too bad!

Great work @kaiyuan-cheng ! This is indeed a challenging test for z-coordinate, so it is quite useful. My two big comments are 1) can we see what the solution looks like at high resolution (I understand that we need to get GPU working for that --- I will look at that in parallel) and 2) can we investigate whether vertical grid stretching helps?

Some more detail below.

Here are my takeaways:

• for simulations that use a z-coordinate wherein the terrain is very low-lying, we may need very high resolution to resolve the physics correctly

Yes, but this is not an ideal solution as it will increase the computational cost significantly (more vertical grids, together with smaller dt).

• for low resolution simulations with low-lying terrain and/or deep domains, we will probably want to implement a terrain following coordinate

I think we probably will need a terrain-following coordinate.

• (we should work on validation cases that don't have topography too)

Totally.

here are my existing questions:

• does grid stretching (packing resolution near the bottom of the domain) improve accuracy?

I guess stretching grid will help, but I expect it will still require a finer grid (and a smaller dt) to resolve the topography compared to a terrain-following coordinate, which will increase the computational cost.

• what resolution is required for accuracy (perhaps expressed as "how well is the terrain resolved")?

I think it depends on the slope of the terrain.

• what are the characteristics of simulations where we deem that we should move to a terrain following coordinate (horizontal resolution, vertical resolution, domain depth, topography characteristics)?

I guess a terrain-following coordinate would better capture weather phenomena related to topography, such as orographic precipitation and foehn winds. By "better", I mean more computationally efficient.

• "how much" can we stretch the grid before accuracy breaks down? The usefulness of stretching has a limit.
• How much fidelity do we buy by using a better representation of the terrain in a z-coordinate --- eg cut cells versus partial cells?

a few comments:

• if we are using a terrain-following coordinate, I think we should also probably move to a fully compressible formulation. The reason is that an anelastic solver for terrain-following coordinates may incur a similar expense as acoustic substepping. (I do think it should be theoretically possible to develop a fast enough solver, but that work is difficult and the gains will probably be marginal)

Agree.

• I think a cut cell implementation is similar or harder than terrain following coordinate, so we shouldn't think of cut cells as a "silver bullet". We should pursue cut cells if partial cells work "ok" and cut cells are an optimization. (the best is of course to pursue both...)

Agree.

At some point we should open an issue to discuss the pros and cons.

Tagging @OsKnoth, @bischtob because he basically told me all of the points that I made above 😂